TOS Silver 2000/TOS Silver 2000.iso/Anwendun/Pov/POVTOOLS/MACHINE/IBMPC/INTEL/Q_A.DOC

Text File | 1995-11-25 | 12.6 KB | 211 lines

POV-Ray Questions & Answers.                                 B.Pulver 5/9/93
-----------------------------------------------------------------------------

This document addresses some of the most commonly asked questions about
POV-Ray and the way it works. It applies only to compiles of POV-Ray done
with Intels "Code Builder Kit" (ICB) 32bit extended DOS compiler. It also
includes some hints on maximizing rendering speed toward the end of the
file.


This document gives a (real) quick overview of the POV-Ray operating
environment. It does not fully describe the options & capabilities of
the 80386+ processors as that would take volumes. It is instead meant
to be a simple FYI type overview for those that may be interested.:

Intel's "Code Builder Kit" creates 32 bit protected mode programs that take
advantage of the enhanced memory management of the 80386+ processors. These
processors have 3 main modes of operation generally known as the "real",
"virtual 86" and "386 protected" modes.

 The "real" mode of operation is what most people are familiar with. In
this mode the CPU "emulates" an 8086/8088 based machine. The 8086 is
capable of addressing 1 meg of memory, to maintain compatibility this
limit is also imposed on the '386/'486 processors when running in this
mode. This is the mode that MS-DOS, and the overwhelming majority of IBM PC
based applications, operate in. The area generally known as "conventional
memory" is the first 640K of this memory block with the second 384K being
used for the built in BIOS ROMS, I/O buffers (such as video) and things
like EMS page frame addresses. That is all the memory the 8086/8088
processors are capable of directly manipulating. Basically a 386/486 running
in real mode is nothing more than a fast 8086 based machine. In actual
operation the 386/486 CPU's *are* capable of using an additional 64K of
memory beyond what the 8086 is capable of. This is what 386/486 memory
managers are referring to at boot time with messages such as "64K high
memory area available". All the memory in the machine must be dealt with in
"chunks" (called segments) no larger than 64K in this mode.

 The "virtual 86" mode is what programs such as Windows run MS-DOS programs
in. Basically the CPU sets up "virtual" machines that all run independently
but retain the limits imposed by running in real mode. In this mode several
programs can be run "at the same time" with all of them thinking they are
running, by them selves, on an 8086 based machine. The advantage of this
mode is that each of the virtual machines may be separated, to some extent,
in hardware (thru the 386+ processors memory management) and is thus less
subject to problems between applications.

 The "386 protected mode" is quite different from both of these modes,
bearing more similarity to CPU's like the Motorola 680x0 series used in the
Macintosh. This is the mode that POV-Ray spends most of it's time running
in. The mode offers the ability to load applications in separate areas of
memory and logically remap that memory to any address in the machine.
Memory available in this mode can be configured as a linear address space
of 4 GigaBytes. (From 0 to 2^32-1 addresses, also called the "flat memory
model".) This memory may be allocated and dealt with at any size, the DOS
64K segment is gone as is the DOS "640K limit". 4,294,967,294 bytes of RAM
are theoretically available to POV-Ray in this mode, of course machine and
compiler limitations dictate what is "really" available. Given a machine
with sufficient resources POV-Ray can directly use 64 megabytes of physical
RAM and (thru the Virtual Memory Manager) additional disk space to total
3.75 Gigabytes of virtual memory.  I.E. POV-Ray has the ability to use 3.75
GIGABYTES of memory. Intels Code Builder (ICB) reserves the first megabyte
of "real mode" memory in the machine for a "scratch pad" area and for
communication with the machines built in BIOS and DOS since THEY are 16 bit
"programs". "Freeing up conventional RAM" has no meaning in this context,
POV-Ray does not use the area for much. The POVRAY.EXE file actually
contains 5 "programs". A Loader/DOS extender (used to add 32 bit
functions to MS-DOS since MS-DOS is a 16 bit operating system), a Virtual
Memory Manager, a protected mode 80387 emulator to provide floating point
math operations in a machine with no CoProcessor installed, and the POV-Ray
program it's self. When POVRAY.EXE is invoked the "loader" is loaded by DOS
& executed, it in turn loads the DOS extender which checks for the presence
of a DPMI *HOST* memory manager. (Common DPMI hosts are Windows, OS/2 2.x in
a DOS VDM, and Quarterdecks QEMM with their QDPMI add on installed. 386MAX is
also supposed to provide it but I have not verified it's operation. I
have tried all the others & they work fine.)

 **** This is where it gets complicated <g> ****  IF an *existing* DPMI
host/memory manager (say Windows) is found to be *already* running the DOS
extender USES IT for ALL memory requests **AND** virtual memory management.
I.E. Windows IT'S SELF provides POV-Ray with all it's memory management and
the configuration of *WINDOWS* imposes the limits on what the program can
use.  (How much extended memory is allocated to the application, the size
that the Windows swap file is, and can go to.... etc.) If a DPMI host is found
to be in operation POV-Ray (ICB) will "gut" it's own virtual memory manager
(since it's not used in this case) to conserve RAM.

 If NO DPMI host is found then the DOS Extender in POV-Ray will provide the
memory management for the program. (It is NOT, however, a DPMI host) The
parameters the program will *expect* to be able to use are set with the
POVMOD program. (Windows, OS/2 and QEMM/QDPMI *must* be configured to
provide *at least* these parameters for POV-Ray to run.
It's *very important* that the program providing the DPMI host services be
configured to provide what POV-Ray *ASKS* for (which is in turn what is set
with POVMOD) or the program will error with an insufficient memory message.)

 The loader/extender then checks to see if a CoProcessor is installed in
the machine. IF NONE IS FOUND the 80387 emulator is loaded. If a
CoProcessor *is* detected the emulator is NOT loaded to conserve RAM. (Note
that the emulator *will not work* correctly in a DOS VDM under OS/2 2.x,
the machine MUST have a CoProcessor installed for the program to function
well. Under Windows 3.x the VEMD.386 driver MUST be installed to run the
program on a machine with no CoProcessor. See the IBMPCEXE.DOC file for
more information.)

 At this point the actual execution of POV-Ray begins.

This is a (very) quick & basic overview of the programs operation and the
environment it executes in.

In answer to some specific questions:

> Does the "virtual memory manager" in POV run only if no existing hard
  disk cache (like SMARTDRIVE) is detected?

No, the virtual memory manager is NOT a disk cache. It provides paged
memory services to POV-Ray in much the same way that a Mainframe or
MiniComputer may use their hard disk drives as "memory". This "memory" appears
to the program to be actual RAM available for it's use. It is NOT a "swap
file" in the conventional sense. (For this reason it's best that the file
used should be located on a drive that *DOES NOT USE DISK COMPRESSION
PROGRAMS* such as STACKER or SUPERSTOR!)  ICB allows this (plus physical
RAM) to go to a total of 3.75 Gigabytes.... if you have a big enough hard
drive.<g>
Disk caching will have little effect on the performance of POV-Ray.
POV-Ray will "tolerate" it's being present, if new enough versions of the
programs are used. (See IBMPCEXE.DOC) A MUCH better way to boost
performance is to use the image buffering built into POV-Ray with the +bxxx
commandline switch. Since POV-Ray must switch out of protected mode to use
the BIOS disk service routines, it takes a performance hit for *every line*
as it is written to disk. Also, since POV-Ray cares little about memory
usage a buffer of 500K is not unreasonable in a machine with at least 4 Megs
of RAM. I've done a couple timing tests and found that trace time can be
reduced by as much as 30% with a 500K or larger buffer.

> What is the minimum amount of conventional DOS memory needed to run
   POV? Does freeing up conventional memory above this minimum improve
   performance?

No minimums are given in the ICB docs, I imagine all that is required is
enough for the loader program to execute since it is (basically) a real mode
program. Be aware however that machines with large amounts of memory taken
up by drivers, TSR's etc. are MORE LIKELY to have some kind of problem with
conflicts between POV-Ray and those drivers. (Simply because they *are*
loaded and the vast differences in the way the CPU it's self is used
between real mode and the 32bit protected mode.) Performance is not
effected by how much real mode memory is available, POV-Ray runs almost
completely in the area BEYOND the real mode 1meg boundary.

> I assume that if POV-Ray is a protected mode application, you should give
   it as much *extended* memory as possible. How much can it use?

Yep, defiantly. The more the better since, as far as POV-Ray is concerned,
this IS the memory. That is where the program actually runs. See
IBMPCEXE.DOC for info on what switches to use with various memory managers
to insure that extended memory is available for POV-Ray. As previously
described, POV-Ray (ICB's limits) can use 64 megabytes of physical RAM
(the IC's installed in the machine) and additional hard disk space to
total 3.75 Gigabytes of paged virtual memory.
NOTE however that "shortcuts" taken by some *hardware* manufacturers may
limit what is "really" available to the program, even if more is actually
installed in the machine. Generally you are pretty safe in assuming that
16 megabytes of RAM and 32 megabytes of disk space will be usable/available
in *ANY* IBM compatible 386/486 PC with an ISA buss. 48 megabytes of VM
should be plenty for any rendering that will be completed in under a
century.... <g> Also note that I have gotten some messages (2 to be exact)
from people that have been unable to get the program to run in a machine
with only 2 megs of RAM installed. Since the first meg is "reserved" for
real mode use this leaves 1 meg for POV to knock around in. POV is actually
a pretty big program it's self these days, and getting bigger.
4 megs gives it some "breathing space".


> What options will allow the program to run as fast as it can?

Generally the command line options that have the most effect are the image
buffering (+bxxx) and the keyboard abort (+x). The image buffering can
dramatically reduce rendering times. A setting of +b512 on a machine with
4+ megs of RAM is a good compromise between the buffer & how much RAM is
"sacrificed" to the buffer. For instance a 512K buffer will limit an 800x600
image to just 3 disk writes during the image generation instead of ** 600 **.
Depending on the environment, the keyboard abort option (+x) can slow things
quite a bit too. It's most noticeable in multitasking environments since
the keyboard is constantly polled to check for the occurrence of any keypress.

Disabling the display option can give a slight improvement in rendering
speed, but it is generally not a very significant improvement.


A note about benchmarking POV-Ray:

Unfortunatly for benchmarking purposes the images that run the fastest also
tend to have the very widest variations from compiler to compiler. That
results in essentially meaningless comparisons since it doesn't represent the
average performance difference you will see in day to day use of the program.
The ways that various compiler designers implement solutions to functions can
cause -really- wide variations between EXE's, completely dependant on what
image is being rendered. For instance BLOB.POV will render about 20% or so
faster with a Watcom 9.5 compile than the ICB 1.0 compile of version 1.0, but
something like ARCHES.POV is only about 7%-8% faster. A 12% variation between
just 2 images. About a year ago I did a whole bunch of comparisons using a
couple dozen images that used various features of the raytracer. SKYVASE.POV
*generally* seems to result in about the same speed differences between
compilers as what the average results of all those images turned out to be. If
you turn on anti-aliasing things tend to tighten to closer render times too.
Different methods of handling disk access can also skew things, you end up
measuring the I/O efficiency of the compiler rather than the floating point
math capability. You can use the -bxxx image buffering to eliminate, or
at least significantly reduce, that.